The present invention generally relates to radio access networks, and particularly relates to maintaining Quality-of-Service (QoS) for delay-sensitive applications such as Voice-over IP (VoIP) serviced by radio access networks.
Some radio access networks route data in packets. For example, a packet switched radio service such as the General Packet Radio Service (GPRS) is added onto an existing circuit-switched network such as the Global System for Mobile Communications (GSM) network to provide both circuit and packet switched communication services. Enhanced Data rates for GSM Evolution (EDGE) or Enhanced GPRS (EGPRS) is a digital mobile phone technology that allows for increased data transmission rates and improved data transmission reliability in GPRS/GSM networks. EDGE employs an 8-PSK modulation scheme which carries three times more information through an extended signal constellation.
GPRS/EDGE radio networks (GERANs) include a gateway GPRS support node (GGSN) and a serving GPRS support node (SGSN) for supporting packet switched communication. The GGSN provides a gateway between the radio network and the public switched packet data network and/or other GPRS networks. The GGSN implements authentication and location management functions. The SGSN controls connections between the radio network and mobile stations. The SGSN performs session management and GPRS mobility management such as handovers and paging. The Base Station Subsystem (BSS) component of a circuit-switched GSM network is updated to support packet switched data communication. For example, a Packet Control Unit (PCU) is provided for converting packet data into a format that can be transferred over the air interface to mobile stations.
Packet data is carried across several interfaces in a GERAN. At each interface, data is packetized according to a particular protocol. For example, application data is sent to a GERAN over the Internet as an IP datagram. The IP datagram is received at the GGSN as a Network Data Packet Unit (N-PDU) which is addressed to a particular IP address. The GGSN encapsulates the N-PDU using the GPRS tunneling protocol (GTP) by adding a GTP header that enables the possibility to tunnel the N-PDUs across GPRS core network. The GTP-PDU is passed to the UDP layer. The UDP layer adds an UDP header to the PDU. The header indicates source and destination port addresses. The UDP-PDU is then forwarded to an IP layer. The IP layer adds SGSN source and destination addresses. The IP layer segments the PDU into smaller units if the PDU is too long.
The IP-PDU is transferred to the SGSN where it is treated as an N-PDU. The SGSN removes the various headers added by the GGSN and provides the N-PDU to a Sub Network Dependent Convergence Protocol (SNDCP) layer. The SNDCP layer converts the N-PDU into a format compatible with the underlying GPRS network architecture. Upon completion, the SNDCP-PDU is passed to a Logical Link Control (LLC) layer. The LLC layer provides a logical connection between the SGSN and mobile stations served by the GERAN. The LLC layer encapsulates the SNDCP-PDU with an LLC header. A Base Station System GPRS Protocol (BSSGP) layer is located directly below the LLC layer and provides routing information so that the LLC-DPU is properly routed to the BSS (e.g. over a frame relay physical layer). The BSSGP operates between the SGSN and the BSS, i.e., the BSSGP does not extend over the air interface.
At the BSS, the LLC-PDU is provided to the Radio Link Control (RLC) layer. The RLC layer establishes a reliable link (e.g. if required by the QoS of the corresponding packet switched service) between the BSS and mobile station. The RLC layer performs segmentation and reassembly of upper-layer PDUs (LLC PDUs in this example) into RLC data blocks. As used herein, the term “upper-layer” means protocol layers above the RLC layer. RLC data blocks consist of an RLC header, an RLC data unit, and spare bits. The RLC data blocks are then passed to a Medium Access Control (MAC) layer which encapsulates the blocks with MAC headers. The MAC layer controls access signaling across the air interface, including the assignment of uplink and downlink radio blocks which are used to carry the RLC data blocks. The data is then transmitted to a mobile station over the air interface via the physical layer. To this end, a Temporary Block Flow (TBF) is established between the BSS and mobile station. The TBF is a logical connection between the BSS and mobile station over which the data is transferred. One or more dynamic (shared) or fixed (dedicated) packet data channels (timeslots) may be assigned when a TBF is established. At the mobile station, the data is received at the physical layer and encapsulation headers are removed from the received data as it moves up the mobile station protocol stack. Eventually, the original application data is received at the application layer.
However, the mobile station may not receive all RLC data blocks after initial transmission by the BSS, e.g., due to poor radio conditions, transmission errors, etc. Similarly, the BSS may not receive the initial transmission of any given RLC data block sent by a mobile station. An RLC data block is considered received when it is received in a layer 1 frame with consistent parity bits as defined in Release 7 of the 3rd Generation Partnership Project RLC/MAC Protocol (3GPP TS 44.060 V7.7.0). RLC data blocks may also be received out-of-order. Each transmitted RLC data block has a sequence number indicating the position of that RLC data block within a sequence of RLC data blocks.
Release 7 of the 3GPP RLC/MAC Protocol enables an RLC receiver endpoint to handle missing RLC data blocks in one of three ways. Case 1; When operating in RLC acknowledged mode, the RLC receiver endpoint sends a packet acknowledged/not acknowledged (ACK/NACK) message to the RLC transmitter endpoint indicating which RLC data blocks are missing. The RLC transmitter endpoint then re-transmits the missing RLC data blocks. Missing RLC data blocks are retransmitted indefinitely in RLC acknowledged mode though the RLC protocol may experience stalling should the number of outstanding (unacknowledged) RLC data blocks grow too large at the RLC transmitting endpoint. Case 2; The RLC transmitter endpoint does not re-transmit any RLC data blocks when operating in RLC unacknowledged mode. Accordingly, in RLC unacknowledged mode missing RLC data blocks are ignored at the RLC receiver endpoint. Case 3; In RLC non-persistent mode, a limited number of RLC data block retransmissions are possible. However, it is not required that all RLC data blocks be correctly received at the RLC receiver endpoint.
For RLC acknowledged mode, the RLC endpoints maintain a sliding window of RLC data blocks based on block sequence numbers (BSN). The sliding window has a predefined width (e.g., 64 blocks for GPRS and 64 to 1024 blocks for EDGE). The RLC receiver endpoint continues to request retransmission of all missing RLC data blocks within the sliding window via a packet ACK/NACK message. This conventional sliding window based approach associated with RLC acknowledged mode is also used for RLC non-persistent mode. The conventional sliding window based approach is used for determining which RLC data block should be negatively acknowledged (NACK) by the receiving RLC endpoint or re-transmitted by the transmitting RLC endpoint. However, it creates QoS issues for delay-sensitive applications such as VoIP given the relatively long round-trip signal propagation times associated with the receiving RLC endpoint sending a NACK to transmitting RLC endpoint and the subsequent retransmission of missing RLC data blocks. Delay-sensitive applications such as VoIP have maximum packet data transfer delay constraints that must be met to assure sufficient QoS from a user perspective. For example, maximum mouth-to-ear speech frame propagation for VoIP is typically 300 ms or less. Missing speech frames received after a 300 ms delay may result in user perception of degraded speech call quality.
For example, based on current radio conditions, a low-throughput Modulation and Coding Scheme (e.g., MCS-1) is selected as the coding scheme for a bi-directional TBF established to support a VoIP service. A particular form of header compression (e.g. robust header compression or ROHC) is also negotiated when the TBF is established (e.g. by the SNDCP layer). Accordingly, one or more RLC data blocks are transmitted over the air interface for each RTP/UDP/IP PDU with header compression being applied by SNDCP (i.e. for VoIP, the full protocol stack involves RTP/UDP/IP/SNDCP/LLC PDUs being carried by one or more RLC data blocks). Further, for packet services having a low transfer delay attribute (such as VoIP), RLC non-persistent mode is selected instead of RLC acknowledged in order to avoid issues resulting from considering all RLC data blocks covered by the sliding RLC window as inherently valid and always subject to re-transmission. This way, a limited number of retransmissions can be made (if necessary) for each RLC data block in an effort to achieve an acceptably low frame error rate without exceeding a maximum overall transfer delay as allowed by the VoIP application when conveying speech frames over the air interface. In other words, RLC non-persistent mode establishes the validity of RLC data based on considering a transfer delay threshold established at TBF set up time (applicable to both the receiving and transmitting RLC endpoints) while still maintaining the use of the sliding RLC window concept (but not using it to determine the validity of RLC data blocks).
An RLC window size is established by explicit control plane signaling and is configured for both RLC acknowledged mode and RLC non-persistent mode. Though still configured for RLC non-persistent mode, the RLC window size in this case is not used to determine whether or not a missing RLC data block having a sequence number within the sliding RLC window is considered as valid (i.e. still considered as expected by the receiving RLC endpoint and still considered as being subject to re-transmission by the transmitting RLC endpoint). To demonstrate how relying on a fixed RLC window size is not sufficient to determine the validity of missing RLC data blocks for delay sensitive applications (such as VoIP), the following example is presented.
A nominal fixed RLC window size can be established (at initial TBF establishment) based on the ratio X of RLC data blocks required to carry RTP/UDP/IP PDUs required for a given modulation and coding scheme (MCS). Assuming MCS-1, 20 ms of speech per speech (RTP) frame and X=2, the window size could, for example, be set to 8X, meaning 16 RLC data blocks carrying 8 RTP frames (RTP/UDP/IP PDUs) and therefore speech payload as old as 160 ms would be considered valid. As time progresses, radio conditions may improve so that the payload-bearing capacity of each RLC data block doubles (e.g., to MCS-4). At this point, the number of RLC data blocks required to transmit a RTP/UDP/IP PDU is cut in half (i.e. X reduces to 1). Thus, with up to 16 RLC data blocks permitted by the RLC window size, RTP frames as old as 320 ms would effectively be considered as valid based on the initially established window size. Such variations in the amount of time allowed for conveying RTP frames across the air interface can result in exceeding the QoS delay attribute for the VoIP application. Of course, radio conditions may improve beyond MCS-4 as considered here such that buffered RLC data blocks even older than 320 ms would then be considered as valid. This fixed RLC window size approach causes a similar issue at the RLC receiver endpoint where missing RLC data blocks are still expected even though they have been missing for a period of time that exceeds the QoS delay attribute for the VoIP application. It should also be noted that any attempt to dynamically re-negotiate the RLC window size as radio conditions change will in practice be too cumbersome (i.e., control plane signaling intensive) and may actually result in generating service interruptions that would be perceived as a reduced QoS experience.
The nominal fixed RLC window size approach can also cause RTP speech frames to be prematurely considered as no longer valid as shown in the following example. When the MCS coding scheme selected during initial TBF establishment is somewhat higher (e.g. MCS-4), an average of Y RLC data blocks are required to carry each RTP frame (RTP/UDP/IP PDU) transmitted over the air interface. Assuming MCS-4, 20 ms of speech per speech (RTP) frame and Y=1, the window size could, for example, be set to 8Y, meaning 8 RLC data blocks carrying 8 RTP frames (RTP/UDP/IP PDUs) and therefore speech payload as old as 160 ms would be considered valid. As time progresses, radio conditions may deteriorate so that the payload bearing capacity of each RLC data block is cut in half (e.g. to MCS-1). When this occurs, the number of RLC data blocks transmitted for each RTP/UDP/IP PDU doubles (i.e. Y increases to 2). Accordingly, the previously established window size now allows RLC data blocks containing speech payload no older than 80 ms to be considered as valid. Thus, when radio conditions deteriorate, the amount of time for which buffered RLC data blocks (at the transmitting RLC endpoint) or missing RLC data blocks (at the receiving RLC endpoint) are considered valid may be excessively small, resulting in an unnecessarily high speech frame error rate.
In another example, the MCS scheme, number of RLC data blocks per RTP/UDP/IP PDU, header compression, size of a speech sample carried by a single RTP frame and window size are the same as in the first two examples. However, we now consider a temporary stoppage in the flow of speech payload (e.g. when a user stops speaking). The fixed RLC window size approach will once again result in less than optimal performance as follows. When a user stops speaking, the RLC transmitter endpoint may still generate supervisory frames or ‘keep alive’ frames (i.e. Silence Descriptor frames also known as SID frames). Since SID frames contain less payload than RTP frames and are sent less often than RTP frames (e.g. the equivalent of every 8th RTP frame), the overall rate at which RLC data blocks are transmitted is significantly reduced for the period of time where there are no actual speech frames requiring transmission. However, this may result in a reduced buffering demand which may in turn result in the RLC data blocks containing speech frame payload buffered before the silent period was entered as being considered as valid for an excessively long period of time because the RLC window size is fixed and it takes longer for the window edges to be reached (i.e. due to a reduced RLC data block throughput rate experienced during the silent period). Lengthening the time for which RLC data blocks (containing speech frame payload) are considered valid can therefore result in exceeding the QoS delay attribute for the VoIP application as described earlier. Once again, this same scenario can produce a similar issue at the RLC receiver endpoint where missing RLC data blocks are considered valid (i.e. still expected) for longer periods of time than they should be.
In yet another example, the MCS scheme, number of RLC data blocks per RTP/UDP/IP PDU, header compression, size of a speech sample carried by a single RTP frame and window size are the same as in the first two examples. However we now consider low header compression efficiency during TBF establishment typically followed by a subsequent increase (i.e. improvement) in compression efficiency as time goes by. Changes in compression efficiency may then also occur (e.g. due to cell change accomplished using handover) well after the VoIP session has been initially established and a good level of compression efficiency has been established. During periods of low compression efficiency, the number of RLC data blocks required to transmit each RTP/UDP/IP PDU is high (i.e. since RTP/UDP/IP PDUs are larger during periods of low compression efficiency). Further, the fixed RLC window size that is established at initial TBF establishment typically assumes relatively high compression efficiency as would be applicable during steady state conditions. Accordingly, during periods of low compression efficiency, RLC data blocks may quickly become considered as falling outside the fixed (but sliding) RLC window, and thus become treated as invalid (by both the transmitting and receiving RLC endpoints) when in reality they may be well within the transfer delay time allowed for by the delay QoS attribute of the corresponding VoIP application.